1. Field of the Invention
This invention relates generally to a system and method for installing software on a controller that does not require the software to include an authorized security code and, more particularly, to a system and method for installing developmental software on a production vehicle electronic control unit (ECU) that does not require the software to be signed.
2. Discussion of the Related Art
Most modern vehicles include electronic control units (ECUs), or controllers, that control the operation of vehicle systems, such as the powertrain, climate control system, infotainment system, body systems, chassis systems, and others. Such controllers require special purpose-designed software in order to perform the control functions. With the increasing number and complexity of these controllers, and the growing threat posed by developers of malicious software, it is more important than ever to authenticate the source and content of binary files that are loaded on automotive controllers. The consequences of using software that is not properly validated, or worse, maliciously-designed, in a vehicle controller include unintended behavior of the vehicle or its systems, loss of anti-theft features on the vehicle, potential tampering with components such as the odometer, and loss of other vehicle features and functions.
One known digital coding technique is referred to as asymmetric key cryptography that uses digital signatures for authenticating files that are programmed into controllers. As would be well understood by those skilled in the art, asymmetric key cryptography uses a pair of mathematically-related keys, known as a private key and a public key, to encrypt and decrypt a message. To create a digital signature, a signer uses his private key, which is known only to himself, to encrypt a message. The digital signature can later be decrypted by another party using the public key, which is paired to the signer's private key.
Flashing is a well known process for installing software files, calibration files and/or other applications into a flash memory of a vehicle ECU or other programmable device. A bootloader is an embedded software program loaded on the ECU that provides an interface between the ECU and a programming device that is flashing the file. The bootloader may employ asymmetric key cryptography and stores a public key that must be used to decode the digital signature transferred by the programming device before allowing the ECU to execute the software file or calibration file.
When developing and testing new versions of software and calibration files, it is usually desirable to employ a production controller already flashed with existing files as a less expensive alternative to providing a specialized controller for developmental purposes only. When installing developmental software files in a production controller, the file must be properly signed or otherwise authenticated before the ECU will allow the file to be installed. Requiring an authorized user to sign developmental software files and calibration files requires significant effort, time and resources. However, if it is relatively easy to install developmental software files into an ECU that includes by-passing the signature requirement to authenticate a file for an authorized user, then it becomes easier for a hacker to also put the ECU in a configuration to not require the signature. Thus, it would be desirable to provide a secure procedure where a production controller that is being used to test developmental software be instructed to not require a signature to flash that software, but still be secure enough to prevent potential hackers from performing the same operation.
If a large number of production controllers exist for a particular module on a vehicle and a technique was developed to flash developmental software onto one of those controllers for testing and development purposes, if that technique ever was released outside of the secure development environment, all of those production controllers could then be vulnerable to that risk. Thus, the technique for instructing a controller to accept developmental software that is not signed for a particular controller of one type needs to be secure enough to prevent a potential hacker from gaining access to that controller, and also needs to be secure enough where if the potential hacker did gain access to that technique for that controller, that technique would not be usable on all of the other controllers of the same type.